<html>
<head>
<title>TDecimate</title>
<link rel="stylesheet" type="text/css" href="../../avisynth.css">
<!--
Automatically generated, don't change:
$Id: tivtc_tdecimate.htm,v 1.1 2005/07/10 16:11:01 wilbertd Exp $ 
-->
</head>
<body>
<h1>TDecimate</h1>
<h2>Abstract</h2>
<b>author:</b>    tritical
<br><b>version:</b>        0.9.9.2<br>
<b>download:</b>   <a href="http://bengal.missouri.edu/~kes25c/">http://bengal.missouri.edu/~kes25c/</a>
<br><b>category:</b>    Deinterlacing &amp; Pulldown Removal
<br><b>requirements:</b>&nbsp;
<ul>
  <li>YV12 &amp; YUY2 Colorspace</li>
</ul>

<p><b>license:</b> GPL</p>

<hr size=2 width="100%" align=center>

<!-- #EndTemplate -->
<h2>Table of Contents
</h2>
<ul>
  <li><a href="#general">    A.) General Info</a></li>
  <li><a href="#basic">B.) Basic Parameters</a></li>
  <li><a href="#advanced">C.) Advanced Parameters</a></li>
  <li><a href="#io-par">D.) File Input/Output Parameters</a></li>
  <li><a href="#debug">E.) Debug/Display Parameters</a></li>
  <li><a href="#overrides">F.) Overrides Info</a></li>
  <li><a href="#overrides">G.) Changelist</a></li>
</ul>
<h2><a name="general"></a>A.)  GENERAL INFO:
</h2>
<p>TDecimate is a decimaton filter intended to remove duplicates from a video stream.  It supports a couple types of operation which include M-in-N decimation
and an arbitrary framerate decimation scheme that can support ratios not achievable
with M-in-N. It also includes special handling for hybrid material such as blend decimation (for a single frame rate solution) or vfr via mkv using a timecodes
file.</p>
<h3>syntax
</h3>
<p><code>TDecimate</code> (clip, int <var>&quot;mode&quot;</var>, int <var>&quot;cycleR&quot;</var>, int
<var>&quot;cycle&quot;</var>, float <var>&quot;rate&quot;</var>, float <var>&quot;dupThresh&quot;</var>, float
<var>&quot;vidThresh&quot;</var>,                  float <var>&quot;sceneThresh&quot;</var>, int
<var>&quot;hybrid&quot;</var>, int <var>&quot;vidDetect&quot;</var>, int <var>&quot;conCycle&quot;</var>, int
<var>&quot;conCycleTP&quot;</var>, string <var>&quot;ovr&quot;</var>, string <var>&quot;output&quot;</var>,
string <var>&quot;input&quot;</var>, string <var>&quot;tfmIn&quot;</var>, string
<var>&quot;mkvOut&quot;</var>, int <var>&quot;nt&quot;</var>, int <var>&quot;blockx&quot;</var>, int
<var>&quot;blocky&quot;</var>, bool <var>&quot;debug&quot;</var>, bool <var>&quot;display&quot;</var>, int
<var>&quot;vfrDec&quot;</var>, bool <var>&quot;batch&quot;</var>,                  bool
<var>&quot;tcfv1&quot;</var>, bool <var>&quot;se&quot;</var>, bool <var>&quot;chroma&quot;</var>, bool
<var>&quot;exPP&quot;</var>, int <var>&quot;maxndl&quot;</var>, bool <var>&quot;m2PA&quot;</var>)</p>
<h2><a name="basic"></a>B.)  BASIC PARAMETERS:
</h2>
<p><var>    mode</var> -</p>
<p>Sets the mode of operation.  Possible settings:</p>
<p>Mode 0 =  Straight M-in-N decimation.  TDecimate will examine each set of N                     frames and decimate the M most similar frames.  The values of M and
N are controlled via the cycleR and cycle parameters.  Blend decimation of video (30p) is supported in the this mode (hybrid = 1).</p>
<p>Mode 1 =  Exactly like mode 0, except instead of decimating the M most similar                     frames, frames are decimated from the longest remaining strings of                     duplicates. The duplicate detection uses the dupThresh parameter.  This                     mode is the correct type of decimation for anime and other sources where                     frames are repeated 2, 3 or 4 times in a row, and also supports blend&nbsp;<br>
                     decimation of video (30p) with hybrid = 1.</p>
<p>Mode 2 =  This mode uses a separate decimation algorithm that can achieve any                     arbitrary framerate.  It is useful when you cannot achieve the desired                     framerate with M-in-N
decimation. The output framerate for this mode is                     set using the "rate" parameter.  The maxndl parameter can be used to
tweak behavior on sources with uneven duplicate distribution. No hybrid                     handling can be used in this mode!</p>
<p>This modes output will be slightly different if you run it with a metrics input file (created on a previous pass in mode 4 for example) that lets
it analyze the entire video at the very beginning than if you run it                     straight and let it analyze the video as it goes.  Generally the differences                     will be small, but the 2 pass method (i.e. full analysis from an input file)&nbsp;<br>
                     will generally produce a smoother result.  The m2PA parameter can be used                     to force the one pass version of mode 2 to produce the same results as the                     two pass version by reading ahead in the stream as much as is required
(the one pass version limits the read ahead to 100 frames max).</p>
<p>Mode 3 =  This is a one-pass vfr for mkv with timecodes output mode.  Hybrid must be
set to 2 in this mode!  It uses M-in-N decimation and cycleR must be set to 1!  The type of decimation that is used on film sections (most similar or
longest string) is controlled via the vfrDec setting.  For this mode to work all access must be linear from start to finish... an error will be thrown
if non-linear access is detected.</p>
<p>Since vfw needs to know the # of frames before processing starts this mode does not change the # of frames and simply pads the output as needed
with black frames.  The last actual frame will be recorded as a comment at the end of the mkv timecodes file, and will be reported on the padded frames
as well once at least 300+ extra frames are returned.  If the se option is set to true, then TDecimate will throw an error once the 306th extra frame
is reached, stopping processing and alerting the user.  If your gonna be                     around when its done and not doing batch encoding this option can save you                     some time.</p>
<p>The name and path of the mkv timecodes file to output is set using the                     mkvOut parameter.&nbsp;</p>
<p>           Mode 4 =  Metrics output.  No decimation is done, but metrics are calculated allowing                     for the output, display, or debug options to be enabled and outputting of                     the metrics for later use.  (first pass for two pass mkv vfr using mode 5)</p>
<p>Mode 5 =  This is similar to mode 3 (mkv vfr, and requires hybrid=2 and cycleR=1), but
as part of a two pass process.  It requires a complete input file (obtained via the output parameter on a previous pass), and a complete tfmIn file (see
the batch option for a way around these requirements).  The advantages of this mode over Mode 3 are that it does not require linear access (seeking is                     supported), it uses the conCycleTP parameter instead of the conCycle parameter                     which allows for values greater then 2, and it will have a correct frame count                     with no padded frames.</p>
<p>Mode 6 =  This is for doing 120fps->vfr w/ timecode file.  It requires a complete metrics
input file generated via mode 4 on a previous pass.  It will decimate bit for bit
identical frames only.  All decimation will be into one of the following frame rates:  119.880, 59.940, 39.960, 29.970, 23.976.</p>
<p>Default:  0  (int)</p>
<p><var>cycleR</var> -</p>
<p>Sets the "M" for the M-in-N decimation modes.  In other words, setting this to 1        means 1 frame in every cycle frames will be dropped.  This setting can be        anything in the range 1-299.  It must be less then the value of the cycle setting!</p>
<p>*NOTE:  all hybrid handling options only support cycleR = 1.  So if hybrid > 0
this value must be set to 1!</p>
<p>Default:  1  (int)</p>
<p><var>cycle</var> -</p>
<p>Sets the "N" for the M-in-N decimation modes.  In other words, setting this to 5        means cycleR frames in every 5 frames will be dropped.  This setting can be        anything in the range 2-300.  It must also be greater then the cycleR setting.</p>
<p>Default:  5  (int)</p>
<p><var>rate</var> -</p>
<p>This sets the output frame rate when using mode = 2.  Frames will be dropped so that this frame rate is acheived while keeping audio/video sync as close
as possible.  This must be less then the input frame rate.</p>
<p>Default:  23.976  (float)</p>
<p><var>hybrid</var> -</p>
<p>Controls how or if video sections (30p) should be dealt with.  Possible        settings:</p>
<p>0 - no handling<br>
            1 - blend decimation (modes 0 and 1)<br>
            2 - vfr via mkv w/ timecodes file output  (modes 3 and 5)</p>
<p>* The hybrid option is not used when mode = 2 or mode = 4, and hybrid > 0 is only currently supported for cycleR = 1!</p>
<p>Default:  0  (int)</p>
<p><var>vfrDec</var> -</p>
<p>Sets the type of decimation to use for film sections when using modes 3 and 5.        Possible settings:</p>
<p>0 - drop most similar frame in cycle<br>
             1 - decimate from longest string of duplicates</p>
<p>Default:  1  (int)</p>
<h2><a name="advanced"></a>C.)  ADVANCED PARAMETERS:
</h2>
<p><var>    dupThresh</var> -&nbsp;</p>
<p>        This sets the threshold for duplicate detection.  This setting is used in mode 1        and also in modes 3 and 5 if vfrDec = 1.  If the difference metric for a frame is less        then or equal to this value then it is declared a duplicate.  NOTE:  metrics will be        slightly different between YV12 and YUY2 processing if chroma=true... the metrics have        been normalized so they should match closely, but on average the YUY2 metrics tend to be        slightly higher (5-10%) then the YV12 metrics for the same frame when chroma=true.        When chroma=false YV12 and YUY2 metrics will be the same, however chroma=false metrics
will be higher then chroma=true metrics so if you set chroma=false be sure to account
for this.  This value is a % of maximum change for a block defined by the blockx and        blocky values.... so 1.1 means 1.1% of maximal possible change.</p>
<p>Default:  1.1  (if chroma = true)  (float)<br>
                  1.4  (if chroma = false)</p>
<p><var>vidThresh</var> -</p>
<p>This setting is used for detecting video sections (30p) based off frame metrics        when hybrid > 0.  If all frames in a cycle have metrics above this threshold then        the cycle is declared video metrics wise.  This setting is similar to dupThresh,        but should be set slightly higher if your vidDetect setting is set to 1 and not 3.        If you know that your source has a lot of video sequences then set this lower vs if        you know your source is pure film then you can set this really high to prevent any        possible misdetections.  This value is a % of maximum change for a block defined by
the blockx and blocky values.... so 1.1 means 1.1% of maximal possible change.</p>
<p>Default:  1.1  (if chroma = true)  (float)<br>
                  1.4  (if chroma = false)</p>
<p><var>sceneThresh</var> -</p>
<p>Sets the threshold for detecting scene changes when using blend decimation for video
sections (hybrid = 1).  This value is a % of maximum change for the luma plane.        Good values are between 10 and 25.  Must be in the range 0 to 100.</p>
<p>Default:  15  (float)</p>
<p><var>vidDetect</var> -</p>
<p>This sets what is required for single cycle video detection when hybrid > 0. Whether
a single cycle alone is enough or whether two consecutive cycles or more must be        detected as video is controlled via the "conCycle" and "conCycleTP" parameters.&nbsp;</p>
<p>        Video detection via frame matches:   (Labeled Type A)&nbsp;</p>
<p>            i.)  The matches that were used by TFM do not indicate that there are duplicates                     in the cycle</p>
<p>Video detection via metrics:   (Labeled Type B)</p>
<p>i.)  All frames in the cycle have metrics above vidThresh.</p>
<p>How these two types of information are used as a whole to determine video sections        is determined by vidDetect.  Each vidDetect setting has a condition that if met will        result in the current cycle being detected as video.  (refer above for the A and B        labels).  Please note that ovr (overrides) overrules vidDetect!</p>
<p>0 - A        (if matches indicate video then consider it video)<br>
	   1 - B        (if metrics indicate video then consider it video)<br>
	   2 - A or B   (if either matches or metrics indicate video then consider it video)<br>
	   3 - A and B  (if both matches and metrics indicate video then consider it video)</p>
<p>Default:  3  (int)</p>
<p><var>conCycle</var> -</p>
<p>conCycle sets the required minimum # of consecutive cycles detected as video for any        section to be considered video when hybrid > 0.  Meaning, if conCycle is set to 2, and        a single cycle is detected as video but both the cycle before it and after it are        detected as film then that cycle will be considered film as well.  If conCycle had been        set to 1 in the previous example then the standalone video cycle would have been consider        video.  This setting is used in all cases except two pass mkv vfr (mode 5) where        conCycleTP is used instead!  The difference is conCycle is limited to a maximum value of
2 while conCycleTP has no upper limit.  Possible values are 1 or 2.</p>
<p>default:  1  if vidDetect = 3  (int)<br>
                  2  otherwise</p>
<p><var>conCycleTP</var> -</p>
<p>This is the same as conCycle, but is used in mode 5 (two pass) and allows for any
value (not just 1 or 2) and has no upper limit.</p>
<p>Default:  1  if vidDetect = 3  (int)<br>
                  2  otherwise</p>
<p><var>nt</var> -</p>
<p>Sets the noise threshold used when calculating difference metrics.  If the abs()        difference between two pixels is less then or equal to this value, then the        difference is considered 0.  This can help lower the metrics of actual duplicate        frames thus widening the difference between dups and non dups making it easier to        set correct thresholds.  Avoid setting this value to high or very similar objects        moving over one another will start to not be detected etc... Good values are in the        range 1-2.  For clean video using a value of 0 seems to work best.</p>
<p>Default:  0  (int)</p>
<p><var>blockx</var> -</p>
<p>Sets the x-axis size of the blocks used for metric calculations.  Larger blocks        give better noise suppression, but also give worse detection of small movements.        Possible values are any power of 2 from 4 up to 2048 (4, 8, 16, 32, ... 2048).</p>
<p>Default:  32  (int)</p>
<p><var>blocky</var> -</p>
<p>Sets the y-axis size of the blocks used for metric calculations.  Larger blocks        give better noise suppression, but also give worse detection of small movements.        Possible values are any power of 2 from 4 up to 2048 (4, 8, 16, 32, ... 2048).</p>
<p>Default:  32  (int)</p>
<p><var>batch</var> -</p>
<p>This setting is intended to be used only with mode 5. Basically, it sets some
arrays to fake values and disables a few checks allowing for an avisynth script        with tdecimate(mode=5, ...) to be loaded when the tfmIn and input files do not        have any entries.  This is useful and needed for setting up a two pass system        in vdub's job control.  i.e. you make the first pass and second pass scripts, and
then set up both to encode in vdub's job control.  NOTE:  if you set batch = true
and the tfmIn and input files do not have entries for all frames then you will<br>
        get borked output!</p>
<p>true - enables fake values and disables checks<br>
            false - doesn't</p>
<p>Default:  false  (bool)</p>
<p><var>tcfv1</var> -</p>
<p>Sets the type of timecode format to use for mkv timecode files when they are created in modes 3 and 5.  The two format types are those defined and used        by mkvtoolnix.  verion 1 sets the framerate for frame ranges while version 2
gives the timecode for each frame in milliseconds.  See the mkvtoolnix documentation
for more info about the two formats.</p>
<p>true - use version 1<br>
            false - use version 2</p>
<p>Default:  true  (bool)</p>
<p><var>se</var> -</p>
<p>Only used when in mode 3.  It will cause TDecimate to throw an error once the 306th
padded frame is reached, alerting the user that it has finished, so that time wont be        spent processing unneeded frames.  This option should not be used when doing batch        encoding or something similar, because the error will usually pop-up a window which requires        the user to click, thus it would stop any subsequent processing as well.</p>
<p>true - stop early (throw error)<br>
            false - don't</p>
<p>Default:  false (bool)</p>
<p><var>chroma</var> -</p>
<p>Sets whether or not chroma is considered when calculating frame difference metrics.        Setting this to false can give a speed up... it a quality vs speed setting (though        in some cases setting chroma=false can improve operation).</p>
<p>true - consider chroma<br>
            false - don't</p>
<p>Default:  true (bool)</p>
<p><var>exPP</var> -</p>
<p>Set this to true if you're using a tfmIn file, have tfm set to PP=1, and are using a        separate filter (such as tdeint) to do post-processing based on tfm's combed frame hints.        If you don't set this to true when PP=1 in tfm, then tdecimate assumes the interlaced        frames marked in the tfmIn file are not being deinterlaced... if this is not the case        (they are actually being deinterlaced by a separate filter) then those frames will not        be handled correctly.</p>
<p>Default:  false (bool)</p>
<p><var>maxndl</var> -</p>
<p>This setting is used only with mode 2 and stands for "max non-duplicate length".  It tells
TDecimate the maximum consecutive number of non-duplicates. This info is used when planning
the decimation strategy.  In normal cases, when duplicates are evenly distributed in the
video, it should not be necessary to set this.  Only in cases where the length indicated<br>
        by the decimation ratio is too short should this need setting.  For example, say we have
the following pattern in a video:</p>
<p>5 5 7 7 2</p>
<p>where the numbers indicate how many frames there are between duplicates.  In this case we
want to remove 5 in every 26 frames.  This decimation ratio (5/26) would indicate that<br>
        there is one duplicate in every 5.2 frames  (5/26 = 1/5.2).  Obviously, as the pattern
above shows, this is the not the case as there are runs of up to 7 without a duplicate. So
we would need to set maxndl to 7.&nbsp;</p>
<p>        Another example would be decimating a 59.94fps video to 23.976.  This ratio would indicate
one duplicate in every 1.667 (5/3) frames.  However, if the video has sections where two<br>
        non-duplicates are back to back then maxndl would need to be set to 2 to correctly handle it.</p>
<p><b>EXTRA INFORMATION:</b></p>
<p>While maxndl stands for "max non-duplicate length", it is actually more like a trade off
between maintaining video sync and producing a smooth result.  The larger maxndl is the
more the decimation can be non-uniformly spread throughout the video, which helps the           smoothness of the result in cases where duplicates are not evenly spread.  Anyways,
experiment with increasing maxndl and see what happens.</p>
<p>Possible settings for maxndl are any integer greater than 0.</p>
<p>Default:  not set  (int)</p>
<p><var>m2PA</var> -</p>
<p>Will override the default read-ahead maximum of 100 for mode 2.  This will allow the
one pass mode (metrics not available from an input file) to produce the same results
as if the metrics were available.&nbsp;</p>
<p>**NOTE:  the cycle size could very well be in the 1000's or 10000's, so there is the                  possibility setting m2PA=true could mean the processing will stall for quite                  some time (5-10 minutes or more) when a new cycle starts!!!  Please check the
largest cycle size that will be used using debug=true before setting m2PA=true!</p>
<p>true = override the default maximum<br>
           false = don't</p>
<p>Default:  false  (bool)</p>
<h2><a name="io-par"></a>D.)  FILE INPUT/OUTPUT PARAMETERS:
</h2>
<p><var>   ovr</var> -</p>
<p>Sets the name and path to an overrides file.  An overrides file can be used to
force ranges of frames to be considered film or video and to specify drop frames
or decimation patterns over ranges of frames.  For more info on using an ovr file        see the OVERRIDES section at the bottom of this file.</p>
<p>Default:  ""  (String)</p>
<p><var>output</var> -</p>
<p>Sets the name and path to an output file.  The output file will include all metrics
caculated.  Each line will include a frame number, plus the difference metric, and
the scene change metric.  This file can be used for input (via the input parameter)
on another pass to avoid having to recaculate the metrics or for the mode 5 two pass        vfr support.</p>
<p>Default:  ""  (String)</p>
<p><var>input</var> -</p>
<p>Sets the name and path to a metrics file to use as input.  This file should have
been created with the "output" parameter on a previous pass.</p>
<p>Default:  ""  (String)&nbsp;</p>
<p><var>   tfmIn</var> -</p>
<p>Sets the name and path to an output file from TFM.  This option is only useful
in cases where hybrid > 0.  It means TDecimate wont have to check the actual        frames for hints and can result in a very slight speed up.  The only case where
it is absolutely required is in mode 5!</p>
<p>Default:  ""  (String)</p>
<p><var>mkvOut</var> -</p>
<p>This sets the name and path for the mkv timecodes file that is generated in modes 3 and 5.</p>
<p>Default:  ""  (String)</p>
<h2><a name="debug"></a>E.)  DEBUG/DISPLAY PARAMETERS:
</h2>
<p><var>     debug</var> -</p>
<p>Enabling this will make TDecimate output information about its internal states and
decisions via OutputDebugString().  You can use a program called DebugView from System Internals:</p>
<p><a href="http://www.sysinternals.com/ntw2k/utilities.shtml">http://www.sysinternals.com/ntw2k/utilities.shtml</a></p>
<p>to view this output.  This can be useful in setting thresholds and seeing what is        happening.  To find out exactly what all it shows you'll have to use it ;)</p>
<p>When mode = 2 and debug=true, TDecimate will spit out the cycle sizes for the
series of M-in-N decimations.  That output will look something like this:</p>
<pre>[1004] mode2_cfs 0 = 7 
[1004] mode2_cfs 1 = 7 
[1004] mode2_cfs 2 = 14 
[1004] mode2_cfs 3 = 56 
[1004] mode2_cfs 4 = 392 </pre>
<p>        The last "mode2_cfs # = ##" line shows the largest cycle size being used (the number
after the "=").  So if you set m2PA=true, and the metrics are not available from an        input file, TDecimate will be reading that ## frames (392 in the above case) ahead        in the video stream, and will have to process those many frames at each cycle boundary!</p>
<p>default:  false  (bool)</p>
<p><var>display</var> -</p>
<p>Outputs almost exactly the same information as debug, but draws it on the actual frames
in the upper left hand corner.  This is usually easier to read and use then the debug
output.  To find out exactly what all it shows you'll have to use it ;)</p>
<p>default:  false  (bool)</p>
<h2><a name="overrides"></a>F.)  OVERRIDES:
</h2>
<p>        An overrides file can be used to manually set drop frames, declare video/film sections,
or specify decimation patterns over ranges of frames.</p>
<p><b>specifying video cycles:</b></p>
<p>To specify a range of frames for TDecimate to consider video... first, enter the              starting frame number, then put a comma (","), then enter the ending frame number,
and finally put a "v" as the specifier.  This range is inclusive, meaning that the              starting and ending frame numbers will be counted as video! Remember that video              sections are only considered when hybrid > 0!</p>
<pre>example: 10,334 v</pre>
<p><b>specifying film cycles:</b></p>
<p>Same as video but use "f" as the specifier.  Doing this will only make a difference              when using hybrid > 0 and detecting video sections.  In all the other modes everything              is considered film to begin with.</p>
<pre>example: 10,334 f</pre>
<p><b>specifying drop frames:&nbsp;</b></p>
<p>              To specify a drop frame enter the frame number you want to drop and put a "-" specifier.
If you manually specify more then cycleR drop frames for one cycle then the ones that come<br>
              first chronologically will be used.  If using mode 2, and not an M-in-N decimation mode,
the same restriction applies, but instead of cycleR being the limiter it is an internally
computed number.</p>
<pre>example: 226 -</pre>
<p><b>specifying a decimation pattern:</b></p>
<p>Use the drop frame specifier along with keep frame specifiers (+) as place holders.</p>
<pre>example: 10,334 +-+++</pre>
<p>In this example every 2nd frame will be dropped starting at frame 10 and going to
frame 334.&nbsp;</p>
<p><b>           EXTRA NOTES:</b></p>
<p>1.) If you specify overlapping entries then the entry that comes last in the ovr
file will be used.</p>
<p>2.) All frame number entries correspond to the frame numbers in the input clip                  (i.e. the input into TDecimate).  They do not correspond to the frame numbers after                  decimation (this is the cause of a lot of headaches).</p>
<p>3.) You can only give cycleR drop frames per cycle.  If you specify more then that,                  then the first cycleR worth specified will be used.</p>
<h2><a name="changelist"></a>G.) Changelist</h2>
<p>    06/25/2005  v0.9.9.2<br>
         + Added mode 6 (120fps -> vfr w/ timecodes file).</p>
<p>05/24/2005  v0.9.9.1<br>
         + Added iSSE optimizations for default metric calculation path              (32x32 blocks + nt&lt;=0 + mod 16 width and height).</p>
<p>05/18/2005  v0.9.9<br>
         + First cut at new mode 2 operation.<br>
         + Added maxndl/m2PA parameters, goe with mode 2.</p>
<p>04/19/2005  v0.9.8.3<br>
         + Added exPP parameter, fixes handling of interlaced frames marked in tfmIn files when
PP=1 in tfm and an external post-processor is used to deinterlace the combed frames.<br>
         - Fixed crash caused by above circumstances.</p>
<p>03/13/2005  v0.9.8.2<br>
         + Added missing logic to most similar decimation mode.  It can now correctly handle
panning->static and static->panning areas like longest string.  It can also detect             cycles that need two duplicates dropped.  Assuming match info is present.<br>
         + Tweaked decimation decisions for both longest string/most similar.  These are the decisions
that use the extra info such as match info and d2v rff info from tfm.<br>
         + Added isse luma diff calculation routine for yuy2.<br>
         - Fixed a bug in the longest string decimation decision that utilized match info from tfm.</p>
<p>03/10/2005  v0.9.8.1<br>
         + Scene change metrics are calculated using only luma, regardless of the chroma option.<br>
         + There can only be one change above sceneThresh within the current cycle as well as the
surrounding two cycles for it to be detected as a scene change (as long as cycle length<br>
             is 10 or less).<br>
         + D2V rff duplicate info is taken into account when deciding what frames to drop, instead             of only for hybrid detection.<br>
         + When hybrid > 0 and concycle or concycleTP is greater then 1, single cycles that are detected
as video and that have a scene change detected in them are treated as video.</p>
<p>02/19/2005  v0.9.8<br>
         + Most similar decimation mode now takes duplicate via match info into account.<br>
         + Match duplicate info and d2v duplicate info is shown with debug/display options.<br>
         + rff info from d2v option in tfm is now taken into account when doing hybrid detection.<br>
         + Increased the maximum possible cycle value to 300.</p>
<p>01/08/2005  v0.9.7.2<br>
         - Fixed SetCacheHints being called incorrectly and always defaulting to CACHE_ALL.<br>
         - Small change to protect against overflow with 1.0 weight when blending frames.</p>
<p>01/04/2005  v0.9.7.1<br>
         + Improved longest string decimation algo by having it look for an obvious duplicate case
based off matches/metrics.</p>
<p>01/03/2005  v0.9.7<br>
         - Fixed mode 4 display output saying "mode 3" instead of "mode 4".<br>
         + Added chroma parameter.<br>
         + mode 4 display and debug output now display the sceneChange metrics along with the
block difference metrics.</p>
<p>01/02/2005  v0.9.6.2<br>
         - Fixed incorrect setcachehints call due to checking the value of the wrong argument.<br>
         + Faster and more accurate mmx/sse2 blending routines, thanks to Leak.<br>
         + Optimized the metric calculation routines.  Exactly how much of a speed increase is dependent
on the source being processed.<br>
         + Some other optimizations and internal changes.</p>
<p>12/22/2004  v0.9.6.1<br>
         - Fixed a problem with timecode file generation that would occur in mode 5 with tcfv1 = true.&nbsp;
If the cycle following a cycle that needed 2 dups removed was detected as video then<br>
               an erroneous line would be written to the file.<br>
         - Fixed not initializing mkvOutF file handle.</p>
<p>12/19/2004  v0.9.6<br>
         - Fixed not differentiating between c matches and deinterlaced frames when hybrid > 0
and checking for dups via matches.<br>
         - Fixed crash with debug=true and large cycles (> 50) due to too small of a string buffer.<br>
         - Changed default sceneThresh to 13.<br>
         - conCycle and conCycleTP now default to 1 when vidDetect = 3 and still default to 2
when vidDetect != 3.<br>
         + Added handling for cycles around scene changes which need 2 dups removed.<br>
         + Some other internal changes.</p>
<p>12/14/2004  v0.9.4<br>
         - Fixed problems with longest string decimation and static to panning and panning to
static scene workarounds in longest string decimation.<br>
         + added se parameter (causes mode 3 to stop early once the last actual frame is delivered).<br>
         + mmx and sse2 blending routines now work with any width (not just mod 8 and mod 16).</p>
<p>12/07/2004  v0.9.3<br>
         - fixed outputting of extra timecode entries when using tcfv1=false (v2 format) in               mode 3 or mode 5 and the last frame was not a cycle boundary.<br>
         - fixed incorrect formatting of the first 2 lines of the mkvOut file when
in mode 3 and using tcfv1=false (v2 format).<br>
         + added mmx and sse2 blending routines (used when hybrid = 1)</p>
<p>11/30/2004  v0.9.2<br>
         - fixed mishandling of the last cycle of a clip when in mode 3 and the last cycle was film.<br>
         - removed a mode 5 specific vidDetect = 3 action that wasn't suppose to be there.<br>
         + write blockx and blocky sizes into tdecimate metric log files.<br>
         + timecode v2 format support.</p>
<p>11/28/2004  v0.9.1<br>
         + Added batch parameter.<br>
         + Added crc checking of input/output files to make sure that a file loaded via the
input parameter actually goes with the current video.</p>
<p>11/27/2004  v0.9<br>
         - Initial release.</p>
<p><kbd>$Date: 2005/07/10 16:11:01 $</kbd>
</p>
</body>
</html>
